Captain Agent論文
https://scrapbox.io/files/6672eef6e6854e001c0c2219.png
論文情報
タイトル：Adaptive In-conversation Team Building for Language Model Agents
発行日：2024年5月
著者：Linxin Song et al
所属：University of Southern California
論文のポイント
人間も複雑なタスクを解くときに、チームを作って解決に臨むことからインスパイアされた
チームを動的に形成し、ネストされたグループ会話と振り返りを活用して多様な専門知識を確保し、固定観念的な出力を防ぐもの
既存の手法より、平均精度で21.94%の改善を示した。
従来の手法(Static Build)だと、タスクの動的な変化に対応できなかったり、タスクが複雑だと大量のエージェントを作る必要があった。
https://scrapbox.io/files/6698cd9184a945001cf7787f.png
hiroya_iizuka.icon 映画制作の場合を例に挙げる
Static Build(従来のやり方)
トップダウンに全て最初に決める
プロデューサー（Builder）は、映画の企画段階で、考えられるあらゆるシーンや特殊効果に対応できるよう、大規模なスタッフ（LLM Agent Team）を一度に雇う。
これでは、複雑な映画になればなるほど、スタッフは多くなる。
使われない専門家も常に待機状態になり、コストが高くなる。
撮影中に新しいアイデアが生まれても、既存のチームで対応が必要
Adaptive Build
ボトムアップに柔軟に決める
柔軟な独立系映画制作のようなもの
クリエイティブディレクター（Adaptive Builder）がいて、各シーン（Task Instruction）に応じて最適なクルーを集める。
必要に応じて、業界のデータベースから専門家を探し（Retrieval）
既存のクルーから適任者を選び（Selection）
新しいスキルが必要なら、クルーをトレーニングしたり新人を育成したり（Generation）する
各シーン（Subtask）ごとに最適なチームを組み、映画評論家（Reflector）が常にフィードバックを提供し、作品の質を高める。
Adaptive Buildは、常に変化する制作ニーズに対して最適なリソース（クルー）を配置し、効率的かつ柔軟に映画制作を進められる点が強み。
一方、Static Buildは初期段階で全てを決定するため、予期せぬ変更への対応が難しく、複雑な製作になるほど非効率になる可能性がある。
データセット
https://scrapbox.io/files/669df722630636001c3d7a45.png
結果
https://scrapbox.io/files/669df7ef35af1c001dfb6985.png
タスクに依存せず、全てで良好な結果であった
Captain Agentは、適切なタイミングで異なるエージェントをチームに組み込めている
hiroya_iizuka.icon まるで、会社の採用が成功するかのように
アブレーション研究でも、Static BuildよりAdaptive Buildの方が成績が良い
https://scrapbox.io/files/669fa566a99745001c564ef9.png
ツールライブラリとエージェントライブラリの両者が大事
https://scrapbox.io/files/669fa59ccc4cfb001d42f449.png
概要
複数の大規模言語モデル（LLM）エージェントを活用することは、複雑なタスクに取り組むための有望なアプローチであることが示されています。一方で、特定のアプリケーションのための複数のエージェントの効果的な設計は依然として芸術的な領域にあります。したがって、次の重要な質問に答えることは興味深いものです：
与えられたタスクに対して、どのようにしてLLMエージェントのチームを効果的に構築できるでしょうか？
私たちの新しい適応型チーム構築パラダイムは、Captain Agentと名付けられた革新的なエージェント設計を通じて実現される柔軟なソリューションを提供します。このエージェントは、タスク解決プロセスの各ステップに対してチームを動的に形成し管理し、ネストされたグループ会話と振り返りを活用して多様な専門知識を確保し、固定観念的な出力を防ぎます。これにより、柔軟だが構造化されたアプローチで問題解決を行うことができます。
6つの現実世界のシナリオにわたる包括的な評価により、Captain Agentは既存のマルチエージェント手法を大きく上回り、平均精度で21.94%の改善を示し、タスク固有のプロンプトエンジニアリングを必要とせずに優れたパフォーマンスを提供することが実証されました。
はじめに
人間は、チームを形成し問題を効果的に解決する能力を発展させてきました。これらの能力は、コミュニケーション、社会的認知、問題解決と意思決定、社会的学習と模倣、および共有された意図性に根ざしています。上記の能力の相互作用により、人々は問題に応じて異なるチームを組織し、タスクが確実に成功するようにすることができます。これにより、マルチエージェントシステムにおける重要な問題が浮かび上がります：
与えられたタスクに対して、どのようにLLMエージェントのチームを効果的に構築できるか？
直接的なパラダイムは、タスクの指示に基づいて事前に静的なエージェントチームを構築し、協力してタスクを解決させることです。しかし、この静的構築方法では、タスクサイクル全体に必要なすべての専門知識を持つチームを維持する必要があります。タスクの複雑さが増すにつれて、チームメンバーの総数が大幅に増加する可能性があります。
hiroya_iizuka.icon なるほど、確かにこれは問題よね
常にそのような大規模なチームで進めることは、チームメンバーを効果的かつ効率的に管理することを困難にします。さらに、静的チームはタスク要件の動的な変化や予期せぬ課題に適応する柔軟性に欠ける可能性があります。
先史時代の人間の部族を想像してみてください：全員が全てのタスクに関与していたでしょうか？答えはおそらく否定的です。狩猟を担当する者は医療に参加せず、料理を担当する者は管理に関与しなかったでしょう。
hiroya_iizuka.icon わかりやすい例え
主要なタスクである生存は、各個人のグループがそれぞれの役割とサブタスクを守ることで確保されていました。実際、人間の組織が複雑なタスクを扱う際、タスク解決過程の異なる段階で各サブタスクに対して複数のチームを形成する傾向があります。これにより、タスクの複雑さが要求する多様な専門知識の活用が保証されます。
人間が複雑なタスクのためにチームを組み立てる方法にインスピレーションを得て、我々は新しいマルチエージェントチーム構築パラダイム：Adaptive Build(適応型構築)を導入します。
https://scrapbox.io/files/6698cd9184a945001cf7787f.png
このパラダイムは、タスク解決プロセスにおいて需要が進化するにつれて、特定のスキルと知識を持つエージェントを柔軟に組み立てることを促進します。このパラダイムを実現するために、我々は新しい適応型ビルダーエージェント、Captain Agentを提案します。
これは、会話の中で各問題解決ステップのためのエージェントチームを構築、管理、維持します。Captain Agentには2つの中核的なコンポーネントがあります：
(1)適応型マルチエージェントチーム構築
(2)ネストされたグループ会話と反省
Captain Agentは、最初に一般的なタスク指示を提供できるUser Proxyと通信します。タスクが割り当てられると、Captain Agentは戦略的計画の策定から始めます。この計画には、タスクが成功裏に完了するまで続く循環プロセスが含まれます。
サイクルの最初のフェーズでは、Captain Agentが特定のサブタスクを識別し、必要な役割を概説し、適切なツールを装備したエージェントのチームを組み立てます。
次のフェーズでは、このチームが多目的ツールとの対話を通じてサブタスクに取り組みます。完了後、リフレクターLLMがプロセスを確認し、Captain Agentに詳細な反省報告を提供します。
このフィードバックに基づいて、Captain Agentはチーム構成またはサブタスクの指示を調整してサイクルを繰り返すか、タスクを終了して最終結果を提示します。
我々は、複雑なタスク解決のための最先端のマルチエージェントアプローチと我々の適応型構築アプローチをCaptain Agentと共に、6つの現実世界のシナリオで評価します。これには、多くの数学問題解決(MATH)、データ分析InfiAgent-Dabench、プログラミング、科学的問題解決(Scibench)（物理学と化学）、および世界情報検索(GAIA)が含まれます。 プログラミングだけ、論文見てもデータセットが何かよくわからなかった。
我々の実験結果は、各シナリオに対する詳細な専門知識の指示（例：代数問題の解き方など）ではなく、基本的な指示（例：以下の数学問題を解いてください）のみを使用した場合でも、Captain Agentが様々なシナリオで卓越した能力を示すことを実証しました。
Captain Agentは、各タスクに対して同じプロンプトを使用した場合、他の単一およびマルチエージェント手法やフレームワークと比較して際立った結果を達成し、平均精度で平均21.94%の改善を示しています。静的および適応型構築パラダイムに関する比較研究では、適応型チームが5つのシナリオのうち4つで静的チームを上回り（1つのシナリオでは同等）、異なるシナリオにわたる適応型構築パラダイムの優位性を示しています。また、手作業で作成されたエージェントと手作業で作成されたツールが最終結果に同等に寄与することを実証しました。さらに、我々はネストされたグループ参加者のバックボーンLLMとしてオープンウェイトモデルを組み込むことを探求し、LLaMA-3-70BがGPT-3.5-turboやclaude-3-sonnetなどのブラックボックスモデルを上回る性能を示すことを発見しました。これにより、実際のアプリケーションでコストを削減する方法についてさらに考えることができます。
2. 適応型会話内チーム構築
提案されたCaptain Agentには、2つの主要なコンポーネントがあります：
適応型マルチエージェントチーム構築
エージェントとツールの検索、選択、生成を含む
マルチエージェントシステム内でのネストされたグループ会話と反省メカニズム
https://scrapbox.io/files/6699ee3066aeb8001c3a4547.png
2.1 概要
Captain Agentの全体的なワークフローを図2に示します。
https://scrapbox.io/files/6699ee1c66aeb8001c3a4415.png
タスクが与えられると、Captain Agentはタスク実行前に計画を導き出すようにプロンプトされます。計画に従って、Captain Agentはタスクが完了したと判断し結果を出力するまで、以下の2つのステップを繰り返します：
ステップ1
Captain Agentはまず、我々のプロンプトによって指示されたサブタスクを特定し、このサブタスクに必要ないくつかの役割をリストアップし、それに応じて検索、選択、生成によってエージェントのチームを作成します。
https://scrapbox.io/files/6699f089132b14001c9c97ea.png
これらのそれぞれには、ツールライブラリから検索された事前定義されたツールが装備されます（セクション2.2）
ステップ2
このエージェントチームは、自由形式のツール使用を伴う会話を通じてサブタスクの解決を試みます。
完了すると、リフレクターLLMがCaptain Agentに反省報告を提供し、チームまたはサブタスクの指示を調整するか、または終了して結果を出力するかを決定します（セクション2.3）
2.2 適応型マルチエージェントチーム構築
ステップ1で対応するプロンプトに従ってサブタスクを特定した後、Captain Agentはそのサブタスクのためのいくつかの役割をリストアップします。これらの役割は、検索拡張生成（RAG）によって導かれる検索、選択、および生成プロセスに渡されます。作成されたエージェントには、よく設計されたプロフィール（システムメッセージ）と高品質のツールが装備されます。 https://scrapbox.io/files/6699f089132b14001c9c97ea.png
hiroya_iizuka.icon 起業と似てるな...
hiroya_iizuka.icon 会社の社長が、役割をリストアップし、社員に割り振る
hiroya_iizuka.icon 役割をこなす適切な社員がいなければ、採用活動を行う
我々は図3にプロセス全体を図示しています。
エージェントとツールの検索
https://scrapbox.io/files/6699f3417df1c4001de92efc.png
Captain Agentは、必要なスキルと可能な役割名を含む詳細な説明とともに、n個の必要な役割{ri|i ∈ 1, · · · , n}をプロンプトします。我々は、このプロセスを自然にするためにCaptain Agentのプロンプトで「専門家」を使用します。
次に、役割の説明とライブラリに記録されているエージェント/ツールの説明との間の文エンベディングの類似性に基づいて、上位k1のエージェントと上位k2のツールを検索します。
我々は、役割とライブラリのエージェント/ツール間の説明のエンベディングを計算するためにSentence Transformerを使用し、2つの文間の類似性を評価するための指標としてコサイン類似度を使用します。以下のようになります： https://scrapbox.io/files/6699f1866c574d0022b52340.png
ここで、k1とk2はそれぞれi番目の役割riに対するエージェントライブラリalibとツールライブラリtlibから検索されるエージェントとツールの数です。f(·) ∈ Rmは、Sentence Transformerから抽出された文エンベディングを表します。検索後、各役割にk1個のエージェント候補とk2個の貴重なツールが割り当てられます。我々は、対応するエージェントのシステムメッセージにツール使用指示を挿入することで、エージェント候補を検索されたツールとバインドします。
エージェント選択
https://scrapbox.io/files/6699f385460900001d9cd266.png
我々は、Captain Agentによって与えられた役割の説明と検索されたエージェントの説明に基づいて、最も適切なエージェントを選択するためのLLMベースのエージェントセレクターをプロンプトします。
エージェントセレクターのために、フォーマットが正しいことを確認するためにJSONテンプレートが設計され提供されます。具体的には、我々はエージェントセレクターのための棄権メカニズムを設計しました。これにより、エージェントセレクターは、上位k1の検索された候補リストから役割に適切なエージェントがない場合に「None」を出力することができます。
これにより、irrelevantまたは冗長なエージェントが現在のタスクに強制的に選択されることを防ぐことができます。「None」とマークされた役割は、以下に説明する生成プロセスにさらに進みます。
エージェント生成
https://scrapbox.io/files/6699f3d366aeb8001c3a9d63.png
我々は、前のステップでリンクされたエージェントがない役割のためのエージェント生成プロセスを設計します。
具体的には、Captain Agentによって与えられた役割の説明に従って、エージェントの名前と必要なスキルを生成します。
これらの指示は、一般的なタスクおよびコーディング指示、およびグループチャット指示と組み合わされて、最終的なシステムメッセージとなります。
最終的なシステムメッセージは、ネストされたグループ会話（次のサブセクションで紹介）で消費される単一の文の説明に圧縮されます。
次に、我々は説明に基づいてツールライブラリからツールを検索し、生成されたシステムメッセージにツール使用指示を挿入します。
生成されたエージェントは、その後エージェントライブラリに追加されます。
2.3 ネストされたグループ会話と反省
適応型マルチエージェントチーム構築プロセスで選択および作成されたエージェントは、ネストされたグループチャットルームに参加します。
彼らは、ユーザーのタスクから情報を収集し、ネストされた会話によってCaptain Agentからのサブタスクを解決するようプロンプトされます。
その後、我々はリフレクターLLMに会話履歴を取得して確認し、結論、結論の理由、可能な矛盾や問題を事前設計されたテンプレートに記入し、結果がダブルチェックを必要とするかをフラグ立てするようプロンプトします。
ネストされたグループ会話
我々は、新しく設計されたツール使用パラダイムを備えたAutoGen フレームワークを活用して、ネストされたグループ会話を実行します。AutoGenは、すべてのエージェントをチャットルームに配置し、会話履歴と各エージェントのアイデンティティに基づいて、グループチャットマネージャーLLMによって各ターンのスピーカーを選択します。 エージェントのプロフィールから短い説明がグループチャットマネージャーのために生成されます。エージェントのコードとツール呼び出しは実行され、即座に会話にフィードバックされます。我々は、ツールの説明、Pythonモジュールへのパス、および応答ケースを関連するエージェントのシステムメッセージに挿入します。エージェントは、ツールの説明とパスに従って自由形式のコードを書くことができ、自然にツールをより大きなプログラムに組み込むことができます。すべてのエージェントによって書かれたプログラムは、共有コード実行環境を持つユーザープロキシエージェントによって実行され、結果はリアルタイムで会話にフィードバックされます。
会話の反省
会話中のエージェントの出力は、事実の誤り、幻覚、および固定観念を含む一貫性のないものになる可能性があります。他のエージェントが会話の中でこれを調整および修正する機会がありますが、彼らも行き詰まり、問題解決の失敗を引き起こす可能性があります。
そのため、我々は、よく設計された会話要約プロンプトテンプレートを使用してリフレクターLLMをプロンプトすることで、そのような会話内の矛盾や問題を検出することを提案します。
リフレクターは、そのような一貫性のない内容を検出した場合、「ダブルチェックが必要」を「はい」とフラグ立てし、詳細な理由を提供します。これにより、Captain Agentは「ダブルチェックが必要」で「はい」を受け取った後、前の結果をダブルチェックするために新しいネストされた会話を構築して検証プロセスを開始します。
2.4 静的構築に対する利点
少数のチームメンバーを持つ静的チームは、チームの能力カバレッジを制限する可能性があります。包括的なペルソナやスキルセットを持つ多数のエージェントを構築することで能力カバレッジの限界に対処できますが、すべての参加メンバーを紹介する長い文脈をLLMが処理することは困難です。
予期せぬ長い文脈は、主に会話の質を低下させます。一方で、冗長な機能を持つエージェントもタスク解決プロセスに関与することになります。
対照的に、Captain Agentは、現在のタスクに対してより最適化されたエージェントチームを適応的に選択および構築することができ、LLMのプロンプト負荷と無関係なエージェントからの冗長な出力を削減しながら、エージェントチームの多様性を犠牲にすることはありません。
hiroya_iizuka.icon ここが一番の利点よね
3. 評価
3.1 実験設定
シナリオとデータセット
評価のために、我々は数学問題解決、プログラミング、データ分析、世界情報検索、および科学問題解決を含む様々な現実世界のシナリオを選択しました。
https://scrapbox.io/files/669df722630636001c3d7a45.png
各シナリオは、エージェントシステムの特定の能力とパフォーマンス指標を示すためにユニークな能力を持つように選ばれました。これにより、計算および認知スキルの重要な次元にわたってCaptain Agentをベースラインと包括的に評価することができます。我々は各シナリオを、表1に示すように挑戦的なオープンソースデータセットとバインドしました。コスト制限のため、我々はMATHから各問題タイプのオリジナルの分布に従ってサブセットをサンプリングしました。
比較方法と実装
数学問題、プログラミング、データ分析、および科学シナリオについて、我々はCaptain Agentと4つの異なる方法のパフォーマンスを調査しました。これには、Vanilla LLM（回答のためにLLMを一度プロンプトする）、AutoAgents、Meta-prompting、およびAutoGenで実現されたエージェントシステム（Executorエージェントを持つAssistantエージェントを含むシステム）が含まれます。
具体的には、我々は公式実装が不安定で大規模実験に適していないため、AutoGenを使用してAutoAgentsを実装しました。
メタプロンプティングについては、AutoGenフレームワークで再現することでコード実行能力を向上させました。Captain Agentについては、エージェントとツールの検索のための文エンベディングを計算するためにall-mpnet-base-v2を採用しました。User Proxy Agentは、コード実行、ツール呼び出し（適応型構築）、ネストされた会話反省結果のフィードバックを提供し、デフォルトの返信：私はプロキシで、あなたのコードとツールを実行するか会話を終了することしかできません。問題が解決されたと思う場合は、'TERMINATE'とだけ返信してくださいを提供することでCaptain Agentと通信します。これらの方法はすべてgpt-4-0125-previewバックボーンを装備し、同じタスク固有のプロンプトを使用します（付録Dを参照）。
世界情報検索シナリオについては、我々はCaptain AgentをGAIA検証リーダーボードに報告されたトップ5のベースライン（参照付き）と比較しました。これには、AutoGen：GAIA_Orchestrator（GAIAのために設計されたOrchestratorエージェントによって組織された特定の3エージェント設定）、FRIDAY、Warm-up Act、およびHuggingFace Agentが含まれます。これらのベースラインはすべてgpt-4-1106-previewバックボーンを持っています。ただし、HuggingFace AgentはバックボーンとしてLLaMA-3-70Bを装備しています。
エージェントとツールライブラリ
我々は、表1に記載された各データセットの問題インスタンスの小さなサブセット（データセットあたり約20問）に基づいて、エージェントライブラリを初期化しました。
具体的には、我々はサブセットでCaptain Agentを実行し、生成されたエージェントを追加してライブラリを反復的に更新し、主要な実験中は我々のエージェントライブラリを変更しないままにしました。我々のエージェントライブラリは、AutoGenにアーカイブされているすべての手作りエージェント（ConversableAgentクラスの）もサポートしています（詳細は付録Fを参照）。
これらのエージェントはすべて、ConversableAgentインターフェースに従って互いに会話します。我々のツールライブラリは、自由形式のコーディングを意図した呼び出し可能なPython関数のスイートで構成されています。エージェントは、ツールライブラリから関数を自由にインポートし、洗練されたタスクを処理するために出力を統合する自由形式のコードを書くことができます（付録EとGも参照してください）。ライブラリには、数学、データ分析、世界情報検索の3つの主要なカテゴリーのツールが含まれています。各カテゴリーについて、我々は対応するデータセットのパターンを要約し、タスクに適した一連の関数を手動で作成しました。
3.2 評価プロトコル
数学、データ分析、科学シナリオについては、各方法からの最終結果と真の解を比較することで、各方法の精度を報告します。評価の公平性を確保するために、我々は異なる結果フォーマットを統一フォーマットに変換し、フォーマットの不一致により正しい答えが不正確と判断されることを防ぎます。プログラミングシナリオについては、各方法から提供されたコードを実行し、コードがすべてのテストに合格した場合に一意のトークンを出力します。その後、成功トークンをカウントし、各方法の精度を計算します。
3.3 主要結果
表2と3は、Captain Agentと8つの異なるベースラインの6つの現実世界のシナリオにおける比較結果を報告しています。世界情報検索に関するベースラインの結果は、GAIAリーダーボードから直接抽出されています。
https://scrapbox.io/files/669df7ef35af1c001dfb6985.png
発見1：多様なエージェントは、問題解決のための正確な専門知識の出力を引き出すのに役立ちます。
Captain Agent、AutoAgents、AutoGen Assistant + Executorの結果を比較することで、我々はCaptain AgentとAutoAgentsが平均して（科学）化学と（科学）物理シナリオでAutoGen Assistant + Executorを上回ることを観察しました。
これらのシナリオは専門知識を必要とし、固定されたシステムメッセージを持つAutoGen Assistantでは完了が困難です。
Captain AgentとAutoAgentsは、エージェントに異なるドメイン固有のシステムメッセージを割り当てることで多様な専門家を作成でき、これがLLM内の固有の知識をより正確に引き出して答えを提供するのに役立ちます。
Captain AgentはすべてのシナリオでAutoAgentsを上回っています。これは、Captain Agentが高レベルの計画を提供し、適応型の指示とエージェントチームで各ステップを解決できるためです。
発見2：適応型チーム構築は、タスクの好みなしでパフォーマンスを向上させます。
Captain Agentがすべてのシナリオで優れた結果を達成していることは明らかで、これはCaptain Agentがタスクの好みから自由であることを示しています。
適切なタイミングで異なるエージェントをチームに組み込むことで、Captain Agentは科学や世界情報検索問題のような難しいタスクをステップバイステップで解決する能力を得ています。
一方、Meta-promptingは、科学問題を1つのエージェントが解決できる細かいサブタスクに分解する能力がないため、科学シナリオで失敗しています。
エージェントチーム構築パラダイムを持つCaptain Agentは、1つのエージェントだけが解決できるサブタスクに分解できるタスクを必要とせず、また全てのエージェントが会話に関与する必要もありません。我々はセクション3.4.1でさらに静的チームと適応型チームについて議論します。
このセクションでは、静的チーム構築と適応型チーム構築の違い、エージェントとツールライブラリの影響、およびオープンウェイトモデルとの連携の可能性について詳しく調べます。
我々は表1からのサブセットで比較研究を行います。具体的には、AutoGenBenchに従ってMATHから17問、HumanEvalから25問を選びました。これらの問題はGPT-4の失敗セットからランダムに選択されています。DABenchについては、25問をランダムに選択し、SciBenchについては、教科書の数に応じて化学と物理学から19問をランダムに選択しました。評価プロトコルはセクション3.3と同じです。
3.4.1 静的vs適応型チーム構築
適応型チーム構築の力をさらに探求するために、我々は適応型チーム構築と静的チーム構築を比較します。具体的には、各タスクの開始時にCaptain Agentと同じ方法でエージェントのチームを構築し、各問題を解決させるタスク固有のチーム構築パラダイムを実行します。結果を表4にまとめました。
https://scrapbox.io/files/669fa566a99745001c564ef9.png
これは、適応型チーム構築パラダイムが静的チーム構築パラダイムを包括的に上回っていることを示しています。
3.4.2 ツールライブラリとエージェントライブラリの比較研究
この部分では、ツールライブラリとエージェントライブラリの有用性について比較研究を行います。我々は、ツールライブラリ、エージェントライブラリ、および両方のライブラリを順番に削除し、世界情報検索タスク、つまりGAIAデータセットでのパフォーマンスを評価します。
表5に示すように、エージェントライブラリとツールライブラリの削除は、どちらもシステムのパフォーマンスを大幅に損なう可能性があります。
https://scrapbox.io/files/669fa59ccc4cfb001d42f449.png
ツールライブラリとエージェントライブラリはどちらも独立してパフォーマンスを向上させることができますが、最適な結果は両方のライブラリを同時に使用した場合にのみ達成されます。
レベル1のタスクの処理には、適度な量のウェブブラウジングと推論ステップが必要であり、これは複数の単一ターンのツール呼び出しや専門家がコードを反復的に書いて実行することで達成できます。エージェントライブラリとツールライブラリの両方を導入することで、システムはウェブインタラクション中の未知のエラーに対してより安定的で堅牢になり、したがってパフォーマンスが向上します。
特に、エージェントライブラリがない場合、Captain Agentはレベル2のタスクでかなり悪いパフォーマンスを示します。これは、これらのタスクがより洗練されており、ほとんどが多数のウェブナビゲーションと推論ステップを含むためです。ウェブブラウジングは複雑で動的なインタラクションを含み、静的なツールライブラリには適していません。エージェントは目標に到達するために複数のツールを調整する必要がありますが、これは予期せぬウェブシナリオでエラーが発生しやすいプロセスです。
hiroya_iizuka.icon Web interactionは複雑で容易にエラーが起こるため、エージェントの役割がより重要になってくる
hiroya_iizuka.icon 例え悪いかもだが、炎上しそうなプロジェクトのPMの重要性と似てる
3.4.3 異なるバックボーンLMを持つネスト会話
このセクションでは、ネストされた会話参加者のために異なるバックボーンLLMを試します。これには、gpt-3.5-turbo、claude-3-sonnet、gemini-1.5-pro、gpt-4-0125-preview（主要結果のデフォルト設定）などのブラックボックスモデルと、LLaMA-3-70B（Meta-Llama-3-70B-Instruct）やMixtral-8x22B（Mixtral-8x22B-instruct-v0.1）などのオープンウェイトモデルが含まれます。
ネストされた会話の指示は、依然としてgpt-4-0125-previewバックボーンを装備したCaptain Agentによって与えられます。実験結果を表6に記録しました。
https://scrapbox.io/files/669fa783a481fb001d177345.png
gpt-4-0125-previewとのネスティングがほとんどのシナリオでSOTAを達成しているという明らかな結果に加えて、gemini-1.5-proもgpt-4-0125-previewよりも約30%安価でよく機能することがわかりました。LLaMA-3-70Bも3つの2番目に良い結果を達成し、gpt-4-0125-previewよりも約16.7倍安価で2つのブラックボックスモデルを上回っています。また、モデルがタスクの好みを持つ可能性があり、ネストされたチャットの質に影響を与えることにも注目しています。例えば、gpt-3.5-turboは優れたコード生成能力を持っており、これがプログラミングシナリオで役立ち、gemini-1.5-proは数学やデータ分析、化学の問題でより良く機能します。
hiroya_iizuka.icon モデル毎に得意分野があるのは面白い。
4. 関連研究
大規模言語モデル（LLM）は人工知能の重要な進歩を表し、推論、計画、新しい現実世界の観察への適応性など、様々な側面で顕著な能力を示しています。多様なシナリオに適応可能な一般化モデルとしてのLLMの固有の多様性を活用し、LLMを基本的なコンポーネントとして機能させる知的エージェントの開発に多くの努力が捧げられてきました。
例えば、代表的なアルゴリズムであるReActは、1つのLLMを使用して推論軌跡とタスク固有のアクションの両方を反復的に生成します。この交互のプロセスにより、エージェントは動的な推論に従事することができます。さらに、LLMエージェントは外部ツールも活用でき、内部能力と外部リソースの両方を活用し、より複雑な問題を効果的に協力して解決することができます。 単一エージェントシステムの成功は、複数エージェントシステムの開発を動機づけています。静的構築に焦点を当てた手法は、エージェントがグループチャットで互いに通信するためのプロトコルと、ユーザーの指示を受け取ってエージェントリストを出力できるビルダーを必要とします。ビルダーは人間またはLLMエージェントである可能性があります。
複雑なタスクをより小さなコンポーネントに分解し、それぞれを詳細な自然言語指示を持つ単一の専門エージェントが処理する他の研究もあります。このタスク分解により、無関係な文脈を避けることで各エージェントの予測負担を軽減します。例えば、メタプロンプティングには、タスクを分解し、異なるLLMにサブタスクを割り当てて完了と集約を行うメタモデルが含まれています。
5. 結論と議論
結論
我々は、マルチエージェントチーム構築の新しいパラダイム、適応型構築を導入します。この新しいパラダイムは、多様性を確保し、限られた知識抽出を防ぎ、固定観念的な出力を減らすのに役立ちます。我々が提案するエージェントであるCaptain Agentによって実行されるこの新しいパラダイムは、適応型マルチエージェントチーム構築とネストされたグループ会話および反省を使用して、問題解決ステップのためのエージェントチームを管理します。6つの現実世界のシナリオにわたる実験結果は、プロンプトエンジニアリングなしで様々なタスクにおけるCaptain Agentの有効性を実証し、既存の手法と比較して優れた結果を達成しています。比較研究は、各コンポーネントが全体的なパフォーマンスに同等に寄与していることを確認し、我々のアプローチの堅牢性を強調しています。
議論
この研究で、我々は6つの現実世界のシナリオにわたるCaptain Agentの優れたパフォーマンスを実証しました。Captain Agentは適応的にチームを組織し、異なるチームによってタスクをステップバイステップで解決することができます。我々は静的なUser Proxyと協力するCaptain Agentのシーンのみを議論していますが、Captain Agentは他の特定のエージェント、例えば洗練されたプランナーと協力することができます。また、文脈の長さと無関係で重要性の低い情報（例：失敗したコードブロック）が問題解決プロセスにノイズを与えることにも気づきました。したがって、会話の刈り込みは、無関係な情報の干渉を最小限に抑えながらコストを削減する有望な将来の研究です。